В сентябре этого года мы писали о VMware Cloud Foundation 3.8.1 - комплексном программном решении, которое включает в себя компоненты VMware vRealize Suite, VMware vSphere Integrated Containers, VMware Integrated OpenStack, VMware Horizon, NSX и другие, работающие в онпремизной, облачной или гибридной инфраструктуре предприятия под управлением SDDC Manager.

На днях компания VMware объявила о выходе обновленной архитектуры VMware Cloud Foundation 3.9.

Давайте посмотрим, что нового появилось в VCF 3.9:

• Поддержка апгрейдов на уровне кластера - теперь есть возможность выбрать отдельные кластеры в рамках домена рабочей нагрузки для обновления хостов ESXi.
• Возможность управления несколькими экземплярами Cloud Foundation из одной консоли.
• Домены рабочей нагрузки Virtual Infrastructure (VI) теперь поддерживают Fibre Channel (в дополнение к vSAN и NFS) как Principal Storage.
• Возможность пересборки конфигураций серверов Dell MX под нужды заказчиков.
• В SDDC Manager можно настроить бэкап NSX Managers на сервер SFTP таким образом, чтобы он находился в отдельной зоне отказа (fault zone). Рекомендуется зарегистрировать сервер SFTP на SDDC Manager после обновления и во время первоначальной настройки.
• Бета-возможность Developer Center - она позволяет получить доступ к Cloud Foundation API и примерам кода под SDDC Manager Dashboard.
• Поддержка Cloud Foundation API была существенно расширена, подробнее об этом рассказано тут.
• Bill of Materials (BoM) был обновлен до последних версий продуктов.

Вот список BoM для релиза VCF 3.9:

Как вы знаете, недавно обновленная платформа виртуализации VMware vSphere 6.7 Update 3 стала доступной для загрузки. Одновременно с этим компания VMware сделала доступной для скачивания и развертывания систему отказоустойчивых кластеров хранилищ VMware vSAN 6.7 Update 3. В обоих этих решениях появилась встроенная поддержка технологии Cloud Native Storage (CNS), о которой мы сегодня расскажем.

Итак, Cloud Native Storage (CNS) - это функциональность VMware vSphere и платформы оркестрации Kubernetes (K8s), которая позволяет по запросу развертывать и обслуживать хранилища для виртуальных машин, содержащих внутри себя контейнеры. По-сути, это платформа для управления жизненным циклом хранения для контейнеризованных приложений.

При этом для такого управления сделано специальное представление в интерфейсе vCenter, которое вы видите на картинке выше.

Основная задача CNS - это обеспечивать развертывание, мониторинг и управление хранилищами для Cloud Native Applications (CNA), то есть современных приложений, исполняемых в контейнерах Docker под управлением Kubernetes (но, кстати, в будущем возможна поддержка и таких платформ, как Mesos и Docker Swarm).

Архитектура CNS реализована двумя компонентами:

• Интерфейс Container Storage Interface (CSI), представляющий собой плагин для K8s.
• Консоль управления CNS Control Plane на сервере vCenter, доступная через vSphere Client.

Через консоль управления CNS администратор может получить представление об имеющихся хранилищах в среде K8s (и видеть маппинги хранилищ на виртуальные диски VMDK), а также управлять ими в большом масштабе, что очень сложно при оперировании на уровне отдельных контейнеров, так как их могут быть сотни на одном хосте ESXi.

Кстати, про оперирование CNS есть интересное видео от VMware:

Надо понимать, что технология CNS появилась не впервые. Ранее подобные функции реализовывал механизм vSphere Storage for Kubernetes (он же vSphere Cloud Provider, VCP). Проект VCP появился как результат внутреннего хакатона VMware, когда требовалось быстро сделать драйвер для кластеров Kubernetes.

До этого приходилось вручную монтировать хранилища контейнеров на виртуальные диски VMDK, что было крайне неудобно, а при большом количестве контейнеров - практически нереально.

Сейчас архитектура VCP реализуется такими решениями Kubernetes as a Service (KaaS), как VMware PKS, RedHat OpenShift, Google Cloud Anthos и Rancher. Для этой архитектуры было возможно 2 режима развертывания - "in-tree" и "out-of-tree". В первом случае VCP был интегрирован в дистрибутив Kubernetes и развертывался одновременно с ним, а во втором - подразумевал последующую интеграцию после развертывания K8s.

Ввиду того, что обновлять VCP при первом варианте развертывания можно было только одновременно с K8s, вариант "in-tree" был исключен из конфигурации развертывания Kubernetes. VMware использовала эту ситуацию для того, чтобы полностью переписать код VCP (который, скорее всего, был не самым оптимальным еще с хакатона) и получить новую архитектуру - CNS.

Также кстати оказалась и покупка компании Heptio (об этом мы упоминали вот тут) - в итоге VMware интегрировала решение CNS прямо в платформу vSphere, без необходимости что-либо развертывать дополнительно. Мало того, архитектура CNS поддерживает любой оркестратор контейнеров, построенный на базе спецификации CSI.

Таким образом, CNS Control Plane на сервере vCenter брокеризует соединение с плагином (на данный момент только для K8s), который уже взаимодействует на уровне Kubernetes.

Частью решения CNS являются First Class Disks (FCDs), о которых мы рассказывали вот тут. Они были придуманы для того, чтобы управлять сервисами, заключенными в VMDK-диски, но не требующими виртуальных машин для своего постоянного существования. Это очень удобно для контейнеров, так как их можно динамически привязывать и отвязывать, не оставляя после себя "осиротевших" VMDK.

Кроме всего этого, CNS полностью подчиняется политикам Storage Policy-Based Management (SPBM), а это значит, что инфраструктура таких хранилищ отлично согласуется с пространством ярусного хранения VMware vSAN и концепцией K8s StorageClass. Также CNS, конечно же, работает и с классическими хранилищами VMFS и NFS, что позволяет использовать политики SPBM на базе тэгов.

Надо отметить, что технология CNS доступна для всех пользователей VMware vSphere, начиная с издания Standard, поэтому платить отдельно за нее не придется. Ну и в заключение обзорное видео о том, что такое и как работает Cloud Native Storage:

Скачать VMware vSphere 6.7 Update 3 с интегрированной технологией CNS можно по этой ссылке.

Как многие из вас знают, с 25 по 29 августа в Сан-Франциско пройдет главная конференция года в области виртуализации - VMworld 2019. На конференции будут представлены сотни докладов, практических семинаров и лабораторных работ, поэтому планировать свое время нужно заранее.

Напомним, что конференцию можно посетить не только лично, но и посмотреть онлайн. Чтобы найти подходящую вам сессию, нужно воспользоваться вот этим порталом поиска. На данный момент там представлено 1032 материала:

Кстати, не забывайте и об онлайн-библиотеке материалов VMworld 2018.

Ну а для тех, кому лень искать по всем этим сотням докладов, блоггер Дункан Эппинг выпустил свой список топ-25 сессий, который мы приведем ниже:

• 60 Minutes of Non-Uniform Memory Architecture [HBI2278BU] от Frank Denneman - все самое главное об архитектуре NUMA на платформе vSphere.
• A Practitioner’s Guide to vCenter Server Architecture [HBI2227BU] от Emad Younis и Sandeep Byreddy - больше подробностей об архитектуре vCenter.
• HCI Management: Current and Future [HCI1207BU] от Junchi Zhang и Christian Dickmann - демонстрация возможностей гиперконвергентной инфраструктуры.
• “If This Then That” for vSphere – The Power of Event-Driven Automation [HCI1379CU] от William Lam и Michael Gasch - средства автоматизации vSphere на базе триггеров событий.
• Hyperconverged Infrastructure: Present and Future [HCI2733BU] от Vijay Ramachandran - о будущем средств управления гиперконвергентной инфраструктурой.
• VMware CTO Panel: What’s Over the Horizon? [OCTO2899PU] от Ray O’Farrell, Pere Monclus, Greg Lavender и Christos Karamanolis - все самые последние новости об инфраструктуре виртуальных ПК VMware Horizon.
• The Virtually Speaking Podcast Live: The Future of Storage [HCI1894PU] от Pete Flecha, John Nicholson, и Ken Werneburg - сессия и живой подкаст о хранилищах.
• PowerCLI Deep Dive [HBI1729BU] от Kyle Ruddy и Luc Dekens - все самое интересное от гуру PowerCLI.
• vSphere Virtual Volumes: Technical Deep Dive [HBI2853BU] от Jason Massae и Thiruvengada Govindan Thirumal - одна из самых интересных сессий, так как именно функциональность VVols развивается самыми мощными темпами.
• VMware Cloud on AWS: SDDC Availability Deep Dive [HBI1924BU] от Jeremiah Megie и Glenn Sizemore - доступность ВМ и данных в публичном облаке - это то, что волнует очень многих.
• Zero to DR in 60 Minutes: VMware Site Recovery DRaaS Technical Deep Dive [HBI1229BU] от Stefan Tsonev и Cato Grace - все самое свежее о катастрофоустойчивых решениях VMware.
• Extreme Performance Series - это маст си о производительности платформы VMware vSphere, где нам покажут новые максимумы платформы и достижения в сфере высокой производительности.
• How GPU-Assisted ML for Medical Research Proved to Be a Force for Good [HBI1546BU] от Niels Hagoort и Johan van Amersfoort - прикладная демонстрация использования алгоритмов машинного обучения на платформе виртуализации. Модно.
• One Storage Platform for Thousands of Cloud Providers [HBI2537PU] от Ari Paul, Rawlinson Rivera и John Toor - рассказ о возможностях S3-совместимого объектного хранилища и vCloud Director для сервис-провайдеров.
• Core Storage Best Practices: Ensuring Your Storage Is Reliable [HBI2751BU] от Jason Massae и Cody Hosterman - на это обязательно надо сходить. Лекция от гуру подсистемы хранения vSphere (VMFS, NFS, VAAI и т.п.).
• Optimizing vSAN for Performance [HCI1757BU] от Paudie O’Riordan - крутая лекция о производительности vSAN.
• Showcase Keynote: Hybrid Cloud Architecture – The New Standard from the Data Center [HYB3544KU] от Kit Colbert, Raghu Raghuram и Mark Lohmeyer - о будущем виртуальных датацентров.
• vSphere Networking in the Data-Centric Future [HBI2136BU] от Sudhansu Jain и Disha Chopra - нам расскажут, что нового ожидается в сетевом стеке датацентров будущего.
• Innovations in vMotion: Features, Performance, and Best Practices [HBI1421BU] от Sreekanth Setty и Arunachalam Ramanathan - что нового еще может быть в vMotion? А вот и расскажут)
• VMware Cloud on Dell EMC: Technical Deep Dive [HBI1975BU] от Mike Hall и Sridevi Ravuri - раньше это называлось Project Dimension. Это создание облачной инфраструктуры SDDC, но на площадке заказчика.
• Encrypting VMs on Standalone Hosts: Tech Preview [HBI1947BU] от Mike Foley и Samyuktha Subramanian - что-то новое о шифровании ВМ.
• Diversity and Inclusion Tech Panel: You Can Drive Success for Women in Tech [PD2632U] от Jodi Shely - оффтопик об участии женщин в ИТ.
• Accelerating Intra-Host PVRDMA Storage Traffic in a Future Dell AMD Server [OCTO2718BU] от Richard Brunner и Shyamkumar Iyer - немного дип-тек хардкора для любителей.
• Edge Computing Innovations in Office of the CTO and Dell Technologies [EIOT2715BU] от Chris Wolf и Daniel Beveridge - новые возможности технологий VMware и Dell от CTO VMware.
• How to Become the Platform Engineer of the Future [PD2248U] от Martijn Baecke и Matthew Steiner - как стать работником будущего, быть актуальным и заработать много денег)

Конечно же, как и всегда, мы будем освещать VMworld 2019. Смотрите также наши обзоры с прошлых конференций:

• VMworld 2018
• VMworld 2017
• VMworld 2016
• VMworld 2015
• VMworld 2014
• VMworld 2013
• VMworld 2012
• VMworld 2011
• VMworld 2010
• VMworld 2009
• VMworld 2008
• VMworld 2007

Многие из администраторов VMware vSphere знают про механизм Storage I/O Control (SIOC) в платформе VMware vSphere (см. также наш пост здесь). Он позволяет приоритезировать ввод-вывод для виртуальных машин в рамках хоста, а также обмен данными хостов ESXi с хранилищами, к которым они подключены.

Сегодня мы поговорим о SIOC версии 2 и о том, как он взаимодействует с политиками Storage Policy Based Management (SPBM). Начать надо с того, что SIOC v2 полностью основан на политиках SPBM, а точнее является их частью. Он позволяет контролировать поток ввода-вывода на уровне виртуальных машин.

SIOC первой версии работает только с томами VMFS и NFS, тома VVol и RDM пока не поддерживаются. Он доступен только на уровне датасторов для регулирования потребления его ресурсов со стороны ВМ, настраиваемого на базе шар (shares). Там можно настроить SIOC на базе ограничения от пиковой пропускной способности (throughput) или заданного значения задержки (latency):

На базе выделенных shares виртуальным машинам, механизм SIOC распределит пропускную способность конкретного хранилища между ними. Их можно изменять в любой момент, перераспределяя ресурсы, а также выставлять нужные лимиты по IOPS:

Надо отметить, что SIOC v1 начинает работать только тогда, когда у датастора есть затык по производительности, и он не справляется с обработкой всех операций ввода-вывода.

Если же мы посмотрим на SIOC v2, который появился в VMware vSphere 6.5 в дополнение к первой версии, то увидим, что теперь это часть SPBM, и выделение ресурсов работает на уровне виртуальных машин, а не датасторов. SIOC v2 использует механизм vSphere APIs for I/O Filtering (VAIO), который получает прямой доступ к потоку ввода-вывода конкретной ВМ, вне зависимости от того, на каком хранилище она находится.

Таким образом, вы можете использовать SIOC v2 для регулирования потребления машиной ресурсов хранилища в любой момент, а не только в ситуации недостатка ресурсов.

Поэтому важно понимать, что SIOC v1 и SIOC v2 можно использовать одновременно, так как они касаются разных аспектов обработки потока ввода-вывода от виртуальных машин к хранилищам и обратно.

SIOC v2 включается в разделе политик SPBM, в секции Host-based rules:

На вкладке Storage I/O Control можно выбрать предопределенный шаблон выделения ресурсов I/O, либо кастомно задать его:

Для выбранной политики можно установить кастомные значения limit, reservation и shares. Если говорить о предопределенных шаблонах, то вот так они выглядят для варианта Low:

Так для Normal:

А так для High:

Если выберите вариант Custom, то дефолтно там будут такие значения:

Лимит можно задать, например, для тестовых машин, где ведется разработка, резервирование - когда вы точно знаете, какое минимальное число IOPS нужно приложению для работы, а shares можете регулировать долями от 1000. Например, если у вас 5 машин, то вы можете распределить shares как 300, 200, 100, 100 и 100. Это значит, что первая машина будет выжимать в три раза больше IOPS, чем последняя.

Еще один плюс такого назначения параметров SIOC на уровне ВМ - это возможность определить политики для отдельных дисков VMDK, на которых может происходить работа с данными разной степени интенсивности:

После того, как вы настроили политики SIOC v2, вы можете увидеть все текущие назначения в разделе Monitor -> Resource Allocation -> Storage:

Недавно компания VMware выпустила новую версию платформы виртуализации VMware vSphere 6.7 Update 2. Довольно много новых возможностей появилось в функциональности управляющего сервера VMware vCenter 6.7 Update 2. Давайте посмотрим, что именно с картинками и анимированными гифками:

На днях компания VMware анонсировала доступность новой версии своей флагманской платформы виртуализации VMware vSphere 6.7 Update 2. Напомним, что предыдущее обновление VMware vSphere 6.7 Update 1 вышло в августе прошлого года.

Давайте посмотрим, что с тех появилось нового:

1. Новое издание VMware vSphere ROBO Enterprise.

Теперь в издании для ROBO-сценариев (Remote or Branch Offices) появились следующие возможности уровня Enterprise:

DRS в режиме обслуживания (Maintenance Mode):

• Доступно только для vSphere ROBO Enterprise.
• Может быть использовано для автоматического перемещения ВМ между хостами (и обратно по окончании процесса). Для этого автоматически создаются правила VM-Host affinity (отслеживается, куда машины уехали перед миграцией, потом запомненные правила применяются - и машины приезжают обратно, где и были изначально).
• Применяются обычные требования vMotion.
• Никакого визуального механизма настройки DRS нет.

Шифрование машин (VM Encryption):

• Шифрование домашней директории и файлов VMDK.
• Требуется инфраструктура KMS.
• Полностью безразлично к гостевой ОС.
• Управляется через GUI или PowerCLI.

2. Обновление архитектуры vCenter Server.

Утилита PSC Converge tool теперь доступна в графическом интерфейсе. Об этом средстве мы писали вот тут, оно позволяет смигрировать внешний сервер Platform Services Controller (PSC) на простой в управлении embedded PSC.

Она дает следующие возможности:

• Конвертация топологии external PSC в Embedded через GUI.
• Можно выполнить шаги по выводу внешнего PSC из эксплуатации (Decomission).

• Все это доступно в разделе System Configuration тонкого клиента vSphere Client (на базе HTML5).
• Можно посмотреть текущую топологию PSC и vCenter в графическом или табличном виде.
• В следующих релизах будет невозможно развернуть внешний PSC, поэтому с него надо уходить.

3. Улучшения резервного копирования и восстановления vCenter Server.

Здесь появилось 2 главных улучшения:

• Новые протоколы, посредством которых вы можете сделать бэкап vCSA - NFS v3 и SMB.
• Нотификации и алармы на успешное и неуспешное завершение задач РК. Эти алармы можно настроить подобно обычным алармам vSphere (послать email, SNMP trap или выполнить сценарий в случае успеха или неудачи).

4. Новые алармы и категории для vSphere Health.

• Опция acknowledgement (заглушить) для алармов vSphere health (как и для обычных алармов).
• Новые категории теперь включают в себя:
  • Online Availability
  • Compute
  • Network
  • Storage
• Эти новые категории позволяют более органично охватывать проблемы сервера vCenter и упрощать управление им.

5. Улучшения Content Library.

• Функции синхронизации шаблонов VM Template (VMTX).
• Шаблоны виртуальных машин теперь можно синхронизировать в автоматическом режиме, как между приватными облаками с серверами vCenter, так и с публичным облаком VMware Cloud on AWS.

6. Улучшения vSphere Client.

• В vSphere Client появилась возможность "code capture" (о ней мы писали вот тут). Теперь она позволяет вести запись пользовательских действий, которые были сделаны в рамках текущей сессии через vCenter API, и генерация соответствующего скрипта. Далее его можно использовать для автоматизации задач в инфраструктуре vSphere.
• Функции API Explorer (доступны в разделе "Developer Center") - простая утилита по поиску в API, которая позволяет найти основные API-вызовы, включая примеры и возможность их тестирования.

• Улучшения пользовательского интерфейса, включая функции attach, compliance check и remediation (все можно делать на одном экране).
• Теперь можно привязать и сделать remediate для нескольких бейслайнов в рамках одной операции.
• Во время remediation можно отключать removable-девайсы от виртуальных машин, включать Quickboot и пропускать проверки vSAN HealthCheck.

8. Улучшения VMware Tools.

• Для Windows Server 2016 тулзы теперь обновляются через Windows update, а значит, что их обновления включены в общий цикл апдейта системы.
• Версия VMware tools for Linux (в формате .TAR) больше не развивается, начиная с VMware Tools 10.3.10, так как OpenVM Tools доступны через любой package update manager.

9. Фикс Host Profiles.

Теперь при применении профиля хоста к ESXi не удаляется интерфейс VMK0, как это было раньше.

10. Улучшения безопасности.

• Windows Server 2019 и RHEL 8 теперь полностью поддерживаются в vSphere 6.7 Update 2.
• Можно применять лимиты для Password History и Reuse.
• Теперь логируются дополнительные события SSO.
• Улучшения ESXi certification API.
• Генерация запроса vCenter Server CSR доступна через GUI клиента.
• vSphere 6.7 Update 2 лучше обрабатывает уязвимости CPU за счет нового планировщика.
• Доступна сертификация NIAP.

11. Улучшения производительности.

• Поддержка 40 & 100Gb Ethernet и RDMA
• Новая версия Virtual Hardware 15 (VM Compatibility):
  • До 256 vCPU на виртуальную машину
  • До 6 ТБ RAM на ВМ
  • Поддержка SAP HANA

На момент написания статьи обновление VMware vSphere 6.7 Update 2 было еще недоступно. Мы обновим пост, когда обновление можно будет скачать.

Многие из вас знают, что у компании StarWind есть продукт Virtual SAN для построения программных отказоустойчивых хранилищ, являющийся на сегодняшний день одним из лидеров отрасли. Но самое интересное, что у StarWind есть и программно-аппаратный комплекс HyperConverged Appliance (HCA), на базе которого можно строить недорогую инфраструктуру виртуализации и хранения для небольших компаний (а также для сценариев ROBO - remote or brunch offices, то есть филиалов).

Продолжаем рассказывать о новых возможностях следующей версии решения для создания отказоустойчивых кластеров хранилищ VMware vSAN. Напомним прошлые статьи этого цикла:

• Что нового будет в VMware vSAN следующей версии, часть 2: поддержка First Class Disk (FCD)
• Анонсы VMworld Europe 2018, часть 3 - технология VMware vSAN Native Data Protection (первая статья серии)

В этой заметке мы поговорим еще об одной возможности, касающейся способов хранения данных в кластере - vSAN Scalable File Services. Как вы знаете, vSAN предоставляет пространство хранения для виртуальных машин и дисков VMDK (в том числе дисков FCD), а также дает возможность использовать логические тома по протоколу iSCSI.

Так вот, функциональность vSAN File Services дает возможность использовать дисковое пространство по протоколам NFS и SMB, что дает возможность раздавать ресурсы кластера через эти протоколы для внешних потребителей без необходимости создания отдельных машин для файловых помоек, например, с Windows Server на борту.

Также файловые шары NFS/SMB будут находиться под управлением политик Storage Policy Based Management (SPBM), а также будут работать в растянутых кластерах vSAN, что позволит рассматривать их как часть общего пространства vSAN в распределенных датацентрах. С помощью SPBM можно будет использовать такие сервисы, как FTT (переносимость отказов хостов ESXi), шифрование и развертывание хранилищ, растущих по мере наполнения данными (thin provisioning).

Механизм файлового шаринга работает на базе файловой системы vSAN Distributed File System (vDFS), которая позволяет агрегировать дисковые объекты vSAN для предоставления пространства хранения, а сервисы управления предоставляет платформа Storage Services Platform.

С точки зрения интерфейса создания и экспорта файловых шар, эти сервисы будет представлять vCenter и vSphere Client (там же будут назначаться права доступа, квоты и прочее).

Сервисы vSAN FIle Server (в демо они были показаны как виртуальные модули, Virtual Appliances) будут реализовывать экспорт папок. Кроме того, они будут иметь механизм обнаружения сбоев и перезапуска этих машин на других серверах:

Такая архитектура также позволит просто апгрейдить хост-серверы ESXi, не останавливая предоставляемые файловые сервисы.

Кроме того, vSAN File Services будут предоставлять свои ресурсы на уровне файлов для контейнеров на платформе Kubernetes:

Также вы можете посмотреть 2 интересных видеопрезентации с VMworld 2018 и VMworld Europe 2018, посвященных vSAN Scalable File Services:

• HCI3041BE – VMworld Europe 2018 session: Introducing Scalable File Storage on vSAN with Native File Services. Также к этому видео прилагается презентация в формате PDF.

• HCI3728KE – VMworld Europe 2018 session:  Innovating Beyond HCI: How VMware is Driving the Next Data Center Revolution.

Подписаться на бету следующей версии продукта VMware vSAN можно по этой ссылке. Ожидается, что первая реализация будет поддерживать NFS 4.1 с аутентификацией в AD, шары SMB, Kerberos, протокол OpenLDAP и механизм vSAN Data Protection.

В мае прошлого года компания VMware выпустила обновление vSphere Integrated Containers 1.4 (VIC), а в июле мы писали про апдейт VIC 1.4.2. В январе этого года VMware выпустила новую версию vSphere Integrated Containers 1.5 - давайте посмотрим, что в ней нового.

1. Квоты хранилищ (Storage Quotas).

Квоты хранилищ позволяют администратору vSphere задавать лимиты хранения, которые доступны объектам Docker Endpoint, с помощью опции --storage-quota для команды vic-machine create. Квоты можно задавать для каждого из объектов Virtual Container Host (VCH), они срабатывают при создании контейнера или загрузке образа. В примере ниже видно, что квота задана на уровне 15 ГБ и при попытке завести еще один контейнер busybox возникает ошибка о превышении квоты по хранилищу.

~$ docker –H :2376 –tls info

vSphere Integrated Containers v1

Backend Engine: RUNNING

VCH storage limit: 15 GiB

VCH storage usage: 9.542 GiB

VCH image storage usage: 1.656 MiB

VCH containers storage usage: 9.451 GiB
~$ docker -H :2376 --tls run --id busybox

  docker: Error response from daemon: Storage quota exceeded. Storage quota: 15GB; image storage usage: 0.002GB, container storage usage: 9.451GB, storage reservations: 9.541GB.

2. Возможность загрузки альтернативного ядра Linux Kernel.

Photon OS дает массу возможностей для загрузки контейнеров, однако некоторым пользователям требуется собственная конфигурация ядра или вообще другой Linux-дистрибутив. Для них сделана возможность загружать собственное ядро, например, ниже приведена команда для запуска ядра CentOS 6.9, в среде которого будут работать контейнеры:

~$ bin/vic-machine-linux create --target 10.161.187.116 --image-store nfs0-1 –user 'administrator@vsphere.local' --bridge-network bridge --public-network management --container-network vm-network --compute-resource cls --no tlsverify --force --name=centos6.9-demo --bootstrap-iso=bin/boostrap-centos-6.9.iso

3. Поддержка VMware NSX-T.

Помимо поддержки решения VMware NSX-V, которая была введена в прошлых версиях, теперь VIC 1.5 поддерживает и решение NSX-T для обеспечения прозрачной коммуникации между контейнерами, с управлением на основе политик и микросегментацией трафика. Делается это с помощью команды vic-machine create –container-network.

Виртуальные машины с контейнерами могут быть подключены к распределенной портгруппе логического коммутатора NSX, что позволяет использовать выделенное соединение этих ВМ к сети:

4. Поддержка Photon OS.

vSphere Integrated Containers 1.5 поставляется со всеми необходимыми компонентами для работы с Photon OS версии 2.0. Этот релиз предоставляет расширенные возможности обеспечения безопасности, а также поддерживает все новые функции второй версии Photon OS.

Получить больше информации о VIC 1.5 можно на этой странице.

Недавно мы писали о политиках хранилищ Storage Policy Based Management (SPBM) на базе тэгов, которые помогают использовать возможности платформы VMware vSphere для назначения виртуальным машинам хранилищ на томах VMFS/NFS с разными характеристиками, который работает на уровне отдельных виртуальных дисков.

Сегодня мы поговорим о политиках SPBM для виртуальных томов VVols на хранилищах, которые предоставляют различные возможности через интерфейс VASA (vSphere APIs for Storage Awareness). Механизм VASA реализуется производителем дисковой системы (storage provider) на программно-аппаратном уровне, при этом дисковый массив полностью отвечает за использование его возможностей, а со стороны vSphere возможно только управление ими средствами механизма SPBM.

Через интерфейс VASA Provider устройство хранения сообщает платформе vSphere, какие сервисы оно предоставляет, а через административный том на хранилище Protocol Endpoint (PE) происходит процессинг операций ESXi с массивом:

К таким возможностям в общем случае относятся:

• Шифрование
• Дедупликация данных на массиве
• Репликация данных внутри массива и на другие массивы
• Функции уровня обслуживания QoS (ограничения по IOPS и Latency)
• Выбор яруса хранения / типа дисков (регулирование уровня производительности)

Также возможна реализация в массиве и других сервисов, таких как защита с помощью снапшотов, использование различных размеров блока для разных приложений и т.п.

Самое приятное в использовании механизма SPBM для хранилищ на основе VVols в том, что вам не требуется заботиться о томах LUN, дисковых группах и настройке их параметров - массив сам распорядится размещением данных по ярусам (Tiers) и датасторам, а также обеспечением уровня их производительности (Service levels).

Например, вот так просто выглядят правила (Rules) для первичного размещения виртуальных машин на массиве EMC Unity при выборе уровня обслуживания и производительности для новой политики SPBM:

В массивах может быть также реализован QoS в зависимости от критичности приложения (Mission Critical приложения всегда первыми получат ресурсы ввода-вывода):

Некоторые хранилища, например, HPE Nimble, могут предоставлять сразу большое число сервисов, для каждого из которых можно настроить свои правила:

Хранилище может предоставлять не только правила размещения виртуальных машин и обеспечения их функционирования, но и сервисы репликации, как например у Pure Storage (они позволяют, в том числе, настроить репликацию на уровне отдельных VMDK дисков машин):

Также создание политик SPBM для томов VVols можно посмотреть на видео ниже:

А вот так применяются политики SPBM, включая сервисы репликации:

Мы уже упоминали о политиках хранилищ SPBM, (Storage Policy Based Management) в кластере VMware vSAN, которые представляют собой очень гибкий механизм для выделения виртуальным машинам хранилищ с разными характеристиками, который работает на уровне отдельных виртуальных дисков.

Политики SPBM разделяются на 3 основных области:

• Storage Capabilities and Services - это политики, которые работают, когда хранилище vSAN или VVols представлено через интерфейс VASA производителем дисковой подсистемы (storage provider). Через VASA это устройство сообщает, какие сервисы оно предоставляет.
• Data Services - это политики, настраиваемые на уровне хоста ESXi, они также реализуются на стороне дискового устройства (storage provider). Эти политики не определяют размещение виртуальных машин, но влияют на их возможности, например, использование шифрования или механизма SIOC.
• Tags - это политики, которые используются хранилищами, которые не предоставляют каких-либо специфических функций, как правило - это обычные тома VMFS и NFS традиционных дисковых массивов без поддержки VASA.

В этой статье мы рассмотрим использование таких объектов, как тэги (Tags) и категории (Categories). Они могут оказаться полезными, когда вы хотите высокоуровнево определить параметры размещения и конфигурации виртуальных машин и их дисков на хранилищах, хостах, кластерах или в других объектах виртуальной инфраструктуры.

Поддержка правил на базе тэгов определяется при создании политики:

С помощью тэгов можно задать ярусы размещения ВМ, конфигурации дисков и их расположение, тип ОС, департамент, к которому принадлежит ВМ, тип дисков SAS/SATA/SSD и многое другое. Вот какие аспекты размещения внутри объектов виртуальной инфраструктуры можно контролировать через категории и тэги:

Например, вы хотите сделать так, чтобы виртуальные машины с гостевой ОС Linux попадали на определенные хранилища. В этом случае надо создать категорию "OS" для объектов Datastore и Datastore Cluster и тэг "Linux", который надо назначить заданным хранилищам. После этого машины с таким тэгом при выборе соответствующей политики SPBM будут попадать на заданные стораджи.

Так, например, может выглядеть конфигурация тэгов и категорий в вашей инфраструктуре:

В рамках одной политики можно использовать до 128 тэгов - это излишне, но если у вас есть фантазия, то вы можете использовать их все) Например, вы можете использовать категорию Department для отдела, а внутри создать тэги для всех отделов: Financial, HR, Engineering и т.п.

Категории и тэги можно использовать для разных аспектов конфигураций хранилищ. Например, тип ОС или тип дисков, на которых размещены ВМ (Category: Disk Type, Tag: SAS).

После создания тэга его нужно добавить к соответствующим датасторам и создать политику, которая использует соответствующие тэги. Это позволит определить размещение виртуальных машин при их создании, миграции или клонированию.

Весь этот процесс показан на видео ниже:

Еще одно преимущество такой механики заключается в том, что вы можете изменить хранилище, которое располагается под политикой, без изменения самой политики. То есть вы добавляете тэг какому-нибудь хранилищу, и оно автоматически попадает в политику с этим тэгом для размещения ВМ. Политику также можно ассоциировать с кластерами хранилищ (datastore clusters), что добавляет еще гибкости этому механизму.

Политики SPBM можно использовать не только отдельно для томов VMFS и NFS, но и для инфраструктуры vSAN и VVols, которые регулируются политиками на уровне хостов (host-based services). Например, можно создать политику, которая позволяет виртуальной машине использовать тома VVols, но только в определенном физическом размещении. Таким образом, с помощью провайдера VASA вы выбираете storage capability как VVols, а с помощью тэгов - физическое размещение ВМ.

Вот как это работает при создании политики:

С помощью PowerCLI вы можете получить информацию о виртуальных машинах или хранилищах, тэгированных определенным тэгом. Вот пример команды для ВМ:

Get-VM -Tag Windows

Name PowerState Num CPUs MemoryGB

---- ------- -------- --------

Windows-VMFS-VM PoweredOff 1 4.000

Win10-3 PoweredOn 2 4.000

jm-ws2016 PoweredOn 2 4.000

Win10-2 PoweredOn 2 4.000

И для хранилища:

Get-Datastore -Tag California

Name FreeSpaceGB CapacityGB

---- --------- ----------

N-VVol-Cali 2,048.000 2,048.000

При использовании механизмов размещения SPBM можно задавать уровень возможности их нарушения (Enforcement). Об этом вы можете прочитать в KB 2142765.

Несколько полезных ресурсов про политики SPBM:

• Storage Policy Based Management
• Populating the VM Storage Policies Interface
• Assign Tags to Datastores
• Storage DRS Integration with Storage Profiles

Некоторое время назад мы писали о продуктах и технологиях, анонсированных на конференции VMworld Europe 2018 (часть 1 и часть 2), а сегодня поговорим о еще одной технологии, объявленной в рамках мероприятия - VMware vSAN Native Data Protection. О ней в своей статье рассказал Viktor van den Berg.

Данная технология будет представлять собой репликацию данных виртуальных машин на уровне хранилищ на базе снапшотов (а также будет доступна локально в рамках хранилища) в целях создания резервных копий ВМ. Работать этот механизм будет в соответствии с текущей механикой политик Storage Policy Based Management (SPBM).

Использовать технологию vSAN Native Data Protection можно для трех сценариев:

• Защита локальных виртуальных машин без использования снапшотов vSphere.
• Репликация данных машин на стороннее хранилище NFS.
• Репликация данных машин на другую площадку (другой кластер vSAN) под управлением того же (или другого) сервера vCenter.

Технология vSAN Local Data Protection будет использовать механизм native vSAN snapshots, который почти не оказывает влияние на производительность ВМ (поскольку работает на уровне хранилища). Также будут поддерживаться консистентные с точки зрения приложений снапшоты, которые будут использовать скрипты Microsoft VSS / VMware Tools для "подморозки" приложений.

Вот так эта настройка будет выглядеть в мастере конфигурации политики хранилищ для ВМ:

Как мы видим, можно установить частоту создания снапшотов (по сути, требования RPO). Далее идет настройка про то, с какой периодичностью делать application consistent снапшоты. Ну и в конце - число хранимых снапшотов.

Некоторые снапшотоы можно будет хранить в течение долгого периода времени в архивных целях:

Также расписание снапшотирования и откидывания на NFS-хранилище будет представлено в таблице:

Сточки зрения восстановления машин из локальных снапшотов, будет использоваться технология Linked Clone, с помощью которой процесс поднятия ВМ будет занимать около одной минуты. Восстановление полностью независимой ВМ займет существенно больше времени (в зависимости от объема хранилища). При восстановлении ВМ можно выбрать кластер, куда восстанавливать, а также VM Network.

Также в процессе работы vSAN Native Data Protection можно просматривать информацию о ее состоянии в целом:

И для виртуальных машин:

Также будет несколько интересных моментов:

• Пока не будет интеграции vSAN Native Data Protection и SRM.
• В будущем планируется создание резервных копий с помощью снапшотов для групп ВМ (consistency groups), если они, например, располагаются на разных хранилищах.
• Минимально RPO можно указать как 5 минут.
• Для обеспечения консистентности бэкапов на уровне приложений можно будет использовать собственные скрипты подготовки и возобновления приложения, а также Microsoft VSS.
• Технология будет интегрирована со сторонними решениями для резервного копирования и фреймворком VADP.
• Репликация на удаленное хранилище также будет использовать снапшоты в своей основе.
• Без application consistent снапшотов (только crash consistent) хранилище будет снапшотиться мгновенно.
• Будет поддерживаться репликация как между разными кластерами, так и между разными vCenter.
• В качестве архивного хранилища будет поддерживаться пока только NFS, но потом можно будет использовать и облачный сторадж Amazon S3.
• Нативные снапшоты будут дедуплицироваться и сжиматься при передаче.

Доступность технологии vSAN Native Data Protection ожидается в первом квартале 2019 года, а пока вы можете запросить доступ к vSAN Beta, где эта технология уже имеется.

Также полистайте вот эту презентацию и посмотрите вот эту запись с сессии VMworld Europe 2018.

Сейчас в Барселоне заканчивается конференция VMworld Europe 2018, которая традиционно проводится после летней конференции VMworld 2018 в США. В отличие от американской конференции, европейская ее версия не содержала так много анонсов новых продуктов и технологий, но кое-что интересное все же было заявлено.

Давайте посмотрим на самые главные новости:

1. Появился VMware vCloud Suite 2018 Platinum.

Компания VMware расширяет функционал своего решения vCloud Suite, которое теперь имеет самое высшее издание - Platinum. Об этом пакете продуктов мы писали последний раз вот тут. В версии 2018 года vCloud Suite содержит в себе следующие продукты:

• vRealize Suite Lifecycle Manager
• vRealize Suite Operations Advanced
• vRealize Suite Log Insight
• vRealize Suite Automation
• vSphere Platinum (напомним, что это комбинация из двух продуктов: платформы VMware vSphere Enterprise Plus и решения VMware AppDefense).

Таким образом, vCloud Suite Platinum = vRealize Suite + vSphere Platinum

Как ни странно, vCloud Suite 2018 Platinum будет доступен в трех изданиях (два из них соответствуют изданиям пакета vRealize Suite):

• vCloud Suite 2018 Platinum – Standard (здесь нет продукта vRealize Automation)
• vCloud Suite 2018 Platinum – Advanced
• vCloud Suite 2018 Platinum – Enterprise

Более подробно об этом пакете продуктов можно узнать из пресс-релиза и на странице решения.

2. Анонсирован VMware Cloud Foundation 3.5.

Еще в начале октября мы писали об анонсе архитектуры Cloud Foundation 3.0, а уже на VMworld Europe 2018 была анонсирована платформа VMware Cloud Foundation 3.5.

Архитектура VCF включает в себя компоненты VMware vRealize Suite, VMware vSphere Integrated Containers, VMware Integrated OpenStack, VMware Horizon, NSX и другие, работающие в онпремизной, облачной или гибридной инфраструктуре предприятия, которые желательно развертывать все вместе, но можно какие-то и опустить.

Вот какие версии продуктов VMware будут в составе VCF 3.5:

Новые возможности обновленной облачной архитектуры:

• Поддержка любых узлов vSAN ReadyNode.
• Поддержка любых сетевых ToR-коммутаторов, которые соответствуют требованиям vSAN.
• Пользователи могут создавать домены рабочей нагрузки (workload domains) для хранилищ NFS, а потом постепенно переносить их на гиперконвергентную архитектуру vSAN.
• Обновление поддерживаемых версий vSphere, vSAN, vRealize и NSX-V.
• Поддержка нескольких площадок и растянутых кластеров (vSAN Stretched Clusters), а также восстановление после сбоев на уровне площадки/региона с разными vCenter.
• Возможность перемещать рабочие нагрузки между сайтами и масштабировать их с помощью технологии NSX Hybrid Connect.

3. Сотрудничество с IBM в сфере облачной инфраструктуры.

VMware договорилась с IBM об использовании инфраструктуры IBM Cloud для предоставления пользователям облачных сервисов виртуальной среды:

Упор делается на обеспечение высокой доступности рабочих нагрузок (виртуальых машин и контейнеров) в этом облаке. Более подробно об этом рассказано здесь.

4. Расширение географии присутствия VMware vCloud on AWS.

На конференции было объявлено о еще большей экспансии публичных облаков VMware и Amazon в Европе и США:

Теперь в географию присутствия сервисов vCloud будут включены датацентры AWS EU (Ireland), AWS West (N. California) и AWS East (Ohio) в четвертом квартале 2018 года.

Завтра мы расскажем об остальных интересных новостях VMworld Europe 2018 - приходите!

Не все администраторы платформы виртуализации VMware vSphere знают, что такое Network I/O Control (NIOC). Причина проста - функции механизма регулирования полосы пропускания NIOC для различных видов трафика на стороне vSphere Distributed Switch (vDS) есть только в издании vSphere Enterprise Plus, которое, как правило, приобретают большие и средние компании.

Давайте посмотрим, что такое NIOC и разберем эту функциональность на примерах. Прежде всего, функция NIOC появилась тогда, когда с появлением сетей 10G стало понятно, что можно делать сетевую инфраструктуру на хостах ESXi с небольшим числом сетевых адаптеров, обладающих высокой пропускной способностью. Но в этих условиях также стало ясно, что сетевой трафик, идущий по таким сетям, надо в рамках того же 10G-канала как-то разграничивать.

NIOC позволяет системным и сетевым администраторам настраивать приоритизацию следующих видов трафика для пула сетевых адаптеров хостов ESXi:

• Fault tolerance traffic
• iSCSI traffic
• vMotion traffic
• Management traffic
• vSphere Replication traffic
• Network file system (NFS) traffic
• Virtual machine (VM) traffic
• User-defined traffic

Механизм NIOC появился еще в 2010 году в VMware vSphere 4.1, и с тех пор был очень сильно доработан (сейчас в vSphere 6.7 Update 1 доступна третья версия NIOC v3).

В интерфейсе HTML5-клиента vSphere Client эти настройки выглядят так (новый клиент полностью поддерживает рабочие процессы NIOC):

В vSphere Web Client вы можете увидеть эти настройки по адресу vDS > Manage > Resource Allocation > System traffic:

Механизм NIOC включен по умолчанию (для vSphere 6.0 и выше), но для типов трафика не заданы никакие ограничения (Limit) и резервации (Reservation) - только приоритеты между типами трафика (Shares). Работают эти 3 техники регулирования типа трафика так же, как и аналогичные механизмы для хранилищ или вычислительных ресурсов:

• Reservation - гарантирует тому или иному типу трафика пропускную способность канала в Мбит/с. Важно помнить, что эта ширина канала резервируется, но в случае ее простоя ее смогут использовать другие типы системного трафика. Между тем, простой канала зарезервированного системного трафика не дает возможность распределить полосу на виртуальные машины. В любом случае, Reservation (если он вам очень нужен) нужно выставлять таким, чтобы обеспечить только минимальные запросы сервиса для его функционирования, а не средние и максимальные.
• Limit - ограничивает сверху используемый канал для выбранного типа трафика.
• Shares - с помощью чисел приоритета (от 1 до 100) позволяет выделить группы которые будут получать больше или меньше пропускной способности канала (например, если одна группа имеет 100, а другая 50 - то первая будет получать в два раза больше на фоне распределения всего трафика адаптеров по группам). Механизм этот начинает распределять канал после раздачи всех заданных резерваций.

Есть еще один нюанс - только 75% совокупной ширины канала на хосте ESXi может быть зарезервировано (а если говорить точнее - от адаптера с самой низкой пропускной способностью в этой группе на хосте). Остальные 25% остаются на всякий случай (например, компенсация всплесков управляющего трафика). Все, что не распределено с помощью Reservation, будет регулироваться средствами механизма Shares.

Для изменения резервации, лимита или shares категорий системного трафика надо открыть настройки конкретного типа трафика:

Для удобства Shares можно указывать не цифрами, а выбрать из комбо-бокса один из вариантов - Low (25), Normal (50) и High (100). В этом случае цифры для Shares автоматически подберутся (они указаны в скобках), чтобы составлять верные соотношения согласно выставленным приоритетам. После выставления этих параметров они будут применены на всех физических адаптерах хостов ESXi, подключенных к распределенному коммутатору vDS на сервере vCenter.

Когда вы задаете Reservation, максимальная пропускная способность для данного типа трафика будет равна этому значению, умноженному на число физических адаптеров на хостах, выделенных для этого типа трафика.

NIOC v3 также позволяет сконфигурировать резервации как на уровне отдельных виртуальных машин (в свойствах адаптера), так и создавать собственные пользовательские пулы (User-Defined Network Resource Pools), которые являются подмножеством корневого пула Virtual machine (VM) traffic.

Для User-Defined Network Resource Pools выставление лимитов и Shares не предусмотрено - только Reservation.

В свойствах адаптера vNIC резервации на уровне отдельной ВМ можно выставить в ее настройках (это только гарантированная полоса, но машина может использовать и больше, если есть доступные ресурсы):

Если вы выставляете Reservation для адаптеров виртуальных машин, то их суммарная резервация не может быть больше, чем резервация для VM system traffic на этом хосте:

Если нужно настроить сетевые пулы ресурсов для групп виртуальных машин, то нужно создать новый пул в Web Client:

А потом указать резервацию для него:

Потом этот пул нужно указать при настройке распределенной группы портов на распределенном коммутаторе vDS:

Ну а к этой распределенной группе портов нужно уже подключить виртуальные машины, которые на всех получат эту резервацию.

При этом если вы задали резервацию 1 Мбит/с, а физических адаптеров на хосте ESXi у вас 5, то такая распределенная группа портов получит до 5 Мбит/с на свои виртуальные машины.

В итоге картина выглядит подобным образом:

Когда вы создадите новый пул в разделе Network Resource Pools, вы сможете посмотреть список виртуальных машин в нем на вкладке Virtual Machines:

Ну и напоследок отметим, что лимиты для сетевых адаптеров машин должны согласовываться с лимитами политики traffic shaping для распределенной группы портов, куда они воткнуты. Например, если для адаптера выставлен лимит 200 Мбит/с, а для всей порт-группы на vDS только 100 Мбит/с, то эффективным ограничением будет именно 100 Мбит/с.

Компания VMware наконец-то обновила свой главный документ о производительности основной платформы виртуализации - "Performance Best Practices for VMware vSphere 6.7". Несколько ранее мы писали о документе "What’s New in Performance - VMware vSphere 6.7", в котором были рассмотрены основные нововведения последней версии продукта в плане производительности, но там было всего 13 страниц, а в этой книге о производительности - аж 88!

Само собой, книга покрывает аспекты не только новой функциональности vSphere 6.7, но и уже давно существующие фичи (с последними обновлениями, конечно). Вот о каких аспектах производительности платформы можно найти информацию в документе:

• Hardware-assisted virtualization
• Storage hardware considerations
• Network hardware considerations
• Memory page sharing
• Getting the best performance with iSCSI and NFS storage
• Getting the best performance from NVMe drives
• vSphere virtual machine encryption recommendations
• Running storage latency-sensitive workloads
• Network I/O Control (NetIOC)
• DirectPath I/O
• Running network latency-sensitive workloads
• Microsoft Virtualization-Based Security (VBS)
• CPU Hot Add
• 4KB native drives
• Selecting virtual network adapters
• The vSphere HTML5 Client
• vSphere web client configuration
• Pair-wise balancing in DRS-enabled clusters
• VMware vSphere update manager
• VMware vSAN performance

Штука эта, очевидно, обязательна к прочтению администраторам vSphere, которые хотят, чтобы у них в инфраструктуре все работало без сбоев и не тормозило.

Несколько интересных моментов из документа:

• Начиная с версии vSphere 6.7, платформа больше не поддерживает программную виртуализацию CPU (только аппаратную).
• vSphere Flash Read Cache (vFRC) может негативно влиять на производительность vMotion.
• Для VVols массив сам обнуляет блоки перед созданием тома, поэтому нет возможности указать тип диска "eager" или "lazy".
• Если вы используете виртуальный сетевой адаптер старой модели с пониженной пропускной способностью, например, Vlance, который показывает в гостевой ОС 10 Мбит/с - это не значит, что он будет работать на этой скорости. Он будет работать на скорости, максимально поддерживаемой физическим оборудованием и хостом ESXi.

Остальные полезные фишки - в документе.

Год назад мы писали об обновлении утилиты RVTools 3.9.2, в котором появилась поддержка VMware vSphere 6.5. В конце февраля вышло обновление этого средства - RVTools 3.10, где появилась масса новых возможностей. Напомним, что RVTools - это утилита, которая помогает администраторам при выполнении рутинных операций с виртуальной инфраструктурой в различных аспектах.

Давайте посмотрим, что нового в RVTools 3.10:

• RVTools теперь сделана на Visual Studio 2017.
• Фреймворк .Net обновлен до версии 4.6.1
• Новые колонки на вкладке vInfo: настройка latency-sensitivity для ВМ, параметры Change Block Tracking (CBT) и значение disk.EnableUUID.
• Новые колонки на вкладке vDisk: SCSI label, unit number и sharedBus.
• Новые колонки на вкладке vHost: назначенные лицензии, ATS heartbeat, значения ATS locking (0 = disabled, 1 = enabled), короткое имя для Host Power Policy, текущая политика CPU Power Management, поддержка CPU power hardware.
• При экспорте в xlsx добавляется версия RVTools и дата/время в выходной файл.
• Все колонки экспортированного xlsx имеют фильтр.
• Новые строчки в csv-файле теперь заменены на пробелы.
• Если утилита работает из командной строки и возникают проблемы с логином - больше не появляется окошко ввода кредов, вместо этого утилита завершается с кодом -1.
• Добавлен пример сценария PowerShell, который позволяет объединять экспортированные xlsx-файлы.
• Добавлен пример сценария PowerShell, который позволяет экспортировать несколько серверов vCenter в один xlsx.
• Вкладка vDatastore: для датасторов NFS колонка с адресом заполняется полным путем к папке вместе с хостом.
• Новые колонки вкладки vDatastore: имя Datastore Cluster, общая емкость кластера и свободные ресурсы хранилищ.
• Верхняя граница хэлсчека (health check) виртуальных машин увеличена до 9999.
• Вкладка vHealth: новая колонка "message type", которую можно использовать как фильтр в Excel.
• Вкладка vHealth: файлы hbrdisk.RDID теперь не определяются как зомби-файлы.
• Вкладка vHealth: при высокой заполненности хранилища показывается также свободная емкость в мегабайтах.
• Все вкладки: обновление и автообновление учитывают порядок пользовательской сортировки.
• Параметры командной строки export2xls обновились на export2xlsx (старые также работают).
• Пакет Log4net обновлен до версии 2.0.8, Waffle.AD - до версии 1.8.3, NPOI - до версии 2.3.0.
• Ошибка соединения для TLSv1.0 и TLSv1.1 отключена и только для TLSv1.2 включена за счет использования .Net Framework 4.6.1.
• Дефолтная директория теперь поменялась на C:\Program Files (x86)\RobWare\RVTools и не содержит номера версии.

Скачать RVTools 3.9.2 для VMware vSphere 6.5 можно по этой ссылке. Документация доступна тут.

Блогер David Pasek опубликовал интересный пост, касающийся ограничения виртуальных машин и их виртуальных дисков по числу операций ввода-вывода. Смысл его в том, что автор, являющийся ярым сторонником обеспечения QoS на уровне виртуальных дисков, настоятельно рекомендует применять ограничения IOPS limit к виртуальным дискам машин, которые потенциально могут выесть много полосы ввода-вывода.

Сейчас ограничивать виртуальные машины по IOPS можно как на уровне виртуальных дисков на томах VMFS/RDM/NFS, так и на уровне томов VVols. Многие системы хранения оперирует понятием логического тома LUN, на котором размещается один том VMFS. Как правило, LUN - это логический том, что значит, что несколько LUN могут размещаться на одной физической группе дисков:

Таким образом, виртуальные машины, потребляющие много IOPS от хранилища (он называет их "noisy neighbor") могут существенно замедлить работу других производственных систем.

Поэтому для таких машин требуется создавать ограничения IOPS limit, которые можно задать для виртуального диска в опциях машин, либо привязать к VMDK диску политику с ограничениями по IOPS.

Например, в vSphere Web Client создаем новую VM Storage Policy с ограничениями IOPS limit for object:

А далее привязываем эту политику к диску VMDK в настройках ВМ:

Тут же в настройках можно задать значение в поле Limit-IOPs, если не выбирать политику.

Именно ограничение по IOPS делает поведение инфраструктуры хранения для виртуальных машин предсказуемым и управляемым. Ограничения по вводу-выводу позволят обеспечить минимально приемлемый уровень обслуживания для виртуальных машин, которым требуются ресурсы хранилища, с гарантией того, что остальные системы не съедят все доступные IOPS.

Ну и в заключение несколько аспектов данного рода ограничений:

• Команды ввода-вывода (IO) нормализуются к блоку 32 КБ, то есть команда в 128 КБ будет преобразована в 4 IO.
• IOPS limit не влияет на операции SVmotion (миграция хранилища), XVmotion (миграция машин без общего хранилища) и клонирование ВМ.
• IOPS limit применяется только ко вводу-выводу гостевой ОС и не затрагивает операции с самим диском VMDK и его swap-файлами.
• Если у машины несколько лимитов по IOPS для дисков на одном датасторе, то эти лимиты складывают и применяются для всей ВМ на этом датасторе в целом. Если же диски находятся на разных хранилищах, то тут уже действуют правила для каждого из групп дисков.
  • Например, если у каждой из 4 дисков машины на одном датасторе стоит лимит 100 IOPS, то для всей машины будет совокупный лимит 400. То есть, если три VMDK едят по 10 IOPS каждый, то четвертый диск сможет съесть максимум 370 IOPS.
  • А вот для NFS-хранилищ все работает несколько иначе - если у каждого из 4 дисков на одном датасторе стоит лимит 100 IOPS, то сколько бы ни потребляли остальные диски, для каждого из дисков будет применен максимальный лимит 100.
• Полная информация об ограничении ввода-вывода для виртуальных машин приведена в KB 1038241.

Также рекомендуем почитать нашу статью "VMware Storage I/O Control (SIOC) - как это работает на практическом примере".

Гостевой пост нашего партнера - сервис-провайдера ИТ-ГРАД, предоставляющего услуги аренды виртуальных машин.

Blockchain — это принципиально новая технология, которая в последнее время приковывает к себе все больше внимания. Специалисты из таких отраслей, как финансы, экономика, медицина, логистика, IoT, активно работают над исследовательскими и экспериментальными проектами с использованием блокчейн, поскольку эта технология заточена не только на криптовалюты.

Отметим, что Hyperledger Fabric — это не компания, не криптовалюта, а проект с открытым исходным кодом, организованный сообществом Linux Foundation, который был создан для продвижения блокчейн-технологии. Это нечто, похожее на хаб для открытой разработки отраслевых блокчейнов. Hyperledger Fabric дает широкие возможности, позволяя разработчикам сконцентрироваться на запуске блокчейн-проекта с собственной бизнес-логикой.

Взгляд изнутри

Суть утилиты Blockchain on vSphere заключается в возможности развернуть несколько узлов кластера Hyperledger Fabric, так называемых Pods, причем максимально просто. При этом в Blockchain-сервисе используются три учетные записи:

• Cloud Admin,
• Blockchain Admin,
• Blockchain Developer.

Каждая из них имеет соответствующие полномочия на разных уровнях системы: Cloud Admin может мониторить и работать с инфраструктурой на базе vSphere, Blockchain Admin — управлять платформой blockchain (Hyperledger Fabric), а разработчик Blockchain фокусируется на разработке приложений с использованием платформы blockchain.

Градация полномочий на разных уровнях системы

Hyperledger Fabric — это распределенная система, реализованная с использованием контейнеров. Она может быть развернута на платформе, которая поддерживает контейнерный стандарт OCI. При этом для управления контейнерами Fabric используется система Kubernetes. В основе рассматриваемого примера для Fabric v1.0 лежит следующая архитектура:

• Используются пространства имен для поддержки различных организаций Fabric.
• Используется настраиваемое количество одноранговых узлов в организации.
• Организуется изоляция через Persistent Volume.

Архитектура решения

Инструкция по развертыванию

Для реализации блокчейн-проекта с использованием Hyperledger Fabric необходимо выполнить ряд предварительных требований, включающих наличие: Читать статью далее->>

Как знают администраторы VMware vSphere, с выходом каждой новой версии платформы увеличиваются и максимумы для ее компонентов. Многие из этих максимумов трудно достижимы на практике, поскольку еще нет серверов такой возможности (например, для запуска такого количества машин в производственной среде), но некоторые аспекты требуют того, чтобы лимиты параметров были увеличены (например, число vNIC на одну машину иногда для тестирования нужно больше).

Давайте взглянем на эволюцию максимумов VMware vSphere в таблицах ниже, где отображены параметры версии 5.5, 6.0 и 6.5:

Максимумы виртуальных машин

Максимумы вычислительных мощностей VMware ESXi

Максимумы хранилищ VMware ESXi

Максимумы сетевого взаимодействия VMware ESXi

Бывает, что попытке развернуть виртуальную машину из шаблона (Template) вы получаете сообщение об ошибке "Customization of the guest operating system is not supported in this configuration":

Как правило, это происходит из-за того, что в машине не установлены VMware Tools. Просто сконвертируйте шаблон в ВМ, потом включите ее и установите тулзы, после чего конвертируйте машину опять в Template.

Также такая ситуация бывает, когда vCenter не поддерживает гостевую ОС виртуальной машины для кастомизации, либо когда развертывание происходит на NFS-хранилище, для которого не включена опция "no root squash".

Это гостевой пост сервис-провайдера ИТ-ГРАД, предоставляющего виртуальные машины в аренду.

Системы хранения данных, являясь основой стабильного функционирования любого предприятия, должны соответствовать параметрам доступности, надежности, безопасности и удовлетворять потребности бизнеса компании. Благодаря таким важным характеристикам СХД, как унифицированность, производительность и масштабируемость, затраты на них сегодня занимают одно из центральных мест в бюджете и составляют в среднем 20–25 % всех расходов. В этой статье мы рассмотрим решения NetApp как наилучшей системы хранения данных для современной компании.

NetApp: более 20 лет инноваций

Для начала предлагаем вспомнить, как развивалась NetApp в исторической перспективе, уделив внимание наиболее значимым моментам.

1992 г. Компания вводит в индустрию систем хранения данных абсолютно новые технологии, представляющие в совокупности законченное решение по хранению данных Network Appliance. На тот момент это была всего лишь файловая шара для Linux, куда позже добавили RAID 4, оптимизацию записи, организацию хранения данных WAFL, поддержку технологии Redirect on Wright (ROW), которая позволяет создавать снимки, не влияя на производительность. С тех пор линейка развивается эволюционно.

1995–1996 гг. Компания выпускает первый мультипротокольный сторадж, представляя технологию файлового доступа для Linux- и Windows-серверов с использованием протоколов SMB и NFS. А после реализует репликацию и поддержку файлового доступа поверх блочного, представляя унифицированную систему хранения данных. С тех пор NetApp пропагандирует консолидацию различных нагрузок на одну СХД и инвестирует в разработку технологий, повышающих эффективность хранения данных.

2007 г. NetApp анонсирует ключевое решение для гибкого клонирования и впервые представляет унифицированную дедупликацию, доступную для всех слоев хранения данных. Таким образом, продуктивный, архивный и медленный слой работают на блочный и файловый доступ. А следующим шагом стала кластеризация...Читать статью далее->>

Недавно компания VMware выпустила интересный документ VMware vSphere APIs for I/O Filtering (VAIO), в котором описываются основные принципы работы данной технологии. Ниже мы расскажем о них вкратце, а также затронем тему того, каким образом можно использовать VAIO в производственной среде.

VAIO - это технология и API, которые позволяют получать прямой доступ к потоку ввода-вывода (I/O Stream) гостевой ОС виртуальной машины. Механизм VAIO уже сейчас способствует созданию партнерских продуктов для решения самых разнообразных задач (например, кэширование write-back и write-through). VAIO основан на механике Storage Policy Based Management (SPBM), которая предназначена для управления правилами хранения виртуальных машин и их работой с хранилищами.

Техническая реализация данного механизма подразумевает использование драйвера VAIO (filter driver), который устанавливается на хосте VMware ESXi как пакет VIB и не требует установки никакого специального ПО в гостевой ОС виртуальной машины.

Посмотрим на эту картинку, на которой изображен путь данных от виртуальной машины к физическому устройству хранения. На ней представлены 2 компонента, относящиеся к VAIO. Первый - это VAIO фреймворк, работающий на уровне ядра VMkernel и определяющий действующую политику фильтра. Второй - это IO Filter, представляющий собой программное обеспечение, работающее на уровне пользовательской среды исполнения (User World) сервера ESXi. Этот драйвер фильтра исполняет свою функцию (например, кэширование данных или их репликация), после чего передает их на физическое устройство хранения для записи.

Такая архитектура позволяет драйверу IO-фильтра получать доступ к потоку ввода-вывода, не сильно не влияя на производительность исполнения SCSI-команд. Еще одна особенность IO-фильтра - это возможность иметь доступ к потоку ввода-вывода как в сторону записи (от ОС к хранилищу), так и в обратную сторону (квитанции о прохождении команд). Это полезно, например, при использовании IO-фильтра для технологии репликации, где очень важно получать квитанции о записи данных на диск.

Кстати, SCSI-команды попадают к IO-фильтру сразу после того, как они проходят слой эмуляции SCSI (он же vSCSI), что позволяет использовать VAIO для любых типов хранилищ - VMFS, NFS, SCSI и vSAN. Ну а перехват команд IO-фильтром перед их отсылкой в сетевой стек к хранилищу позволяет обеспечить целостность данных и безопасность.

Еще, если внимательно посмотреть на архитектуру прохождения потока ввода-вывода, можно заметить, что драйвер IO-фильтра работает на уровне User World, а значит в целом не влияет на стабильность работы сервера ESXi. Даже если он вдруг прекратит свою работу, основной стек прохождения SCSI-команд, расположенный в ядре, продолжит работать в нормальном режиме.

Работает IO Filter на уровне отдельных VMDK-дисков конкретных ВМ, что открывает широкие возможности для механизма политик Storage Policy Based Management (SPBM) и применения их к отдельным виртуальным машинам и сервисам.

Все вышеперечисленное позволяет применять VMware VAIO при решении следующих типов задач:

• Encryption – стороннее ПО за счет использования механизма VAIO может на лету шифровать и расшифровывать поток данных от виртуальной машины. Таким образом на хранилище будут помещаться уже шифрованные данные. Гранулярность работы VAIO позволяет обслуживать данные, идущие даже не от всей виртуальной машины, а только от одного приложения.
• De-duplication - этот механизм уже использует решение VMware Virtual SAN. В реальном времени можно дедуплицировать данные, проходящие через драйвер и в таком виде уже класть на хранилище в целях экономии дискового пространства. Эта техника доступна и партнерам VMware.
• Tiering - данные различной степени важности, критичности или классифицированные по другим критериям теперь можно класть на хранилища с разными характеристиками производительности и доступности (ярусы). Механизм VAIO тут поможет проанализировать характер данных и определить конечное их место назначения.
• Analytics - теперь можно анализировать непосредственно поток данных от конкретной виртуальной машины и на основе этого строить множество различных решений, включая решения по кэшированию (например, такой продукт как PrimaryIO, который можно напрямую подключить к гипервизору). Затем можно, например, искать в трафике данные определенных приложений, либо, использовать механизм write-back кэширования.

Технология VAIO работает, начиная с VMware vSphere 6.0 Update 1, поддерживает горячую миграцию vMotion (VAIO должна быть доступна на целевом хосте) и кластеры VMware DRS (должна быть доступна на всех хостах).

Давайте теперь посмотрим, как VAIO работает на практике на одном из примеров. Чтобы начать работать с VAIO, вам нужно установить IO Filter в виде VIB-пакета, который реализует функциональную составляющую партнерского продукта для VMware vSphere.

Как правило, вместе с фильтром идет и политика SPBM (аналогичная тем, которые есть для vSAN или VVols, например), которую можно назначать виртуальным машинам на уровне виртуальных дисков VMDK.

Эту политику можно назначить при создании виртуальной машины в разделе Select Storage (в данном случае это политика кэширования на SSD):

Пример политики, идущей вместе с фильтром, как правило включает в себя Common Rule - правила, которые реализуют Data Services (то есть основной функционал фильтра) и определяются через компоненты Storage Policy Components (путем добавления компонентов в разделе Common Rules).

Например, в данном случае это тип кэширования Write Through или Write Back, который мы задаем в разделе Common Rules при создании новой политики хранения:

По умолчанию эти компоненты устанавливаются вместе со встроенными фильтрами vSphere и другими продуктами, которые пополняют набор IO-фильтров, а соответственно и компонентов по мере их установки. За счет использования Storage Policy Components возможности IO-фильтров могут быть включены в любую из уже настроенных политик VM Storage Policies.

Это очень удобно, поскольку на данный момент виртуальная машина или VMDK-диск могут иметь только одну примененную к ним политику хранения, но к ним можно добавить компоненты от разных фильтров.

Ну а сами IO-фильтры от разных производителей вы можете найти в VMware Compatibility Guide по этому адресу - https://www.vmware.com/resources/compatibility/search.php?deviceCategory=vaio.

Как видно из картинки, на данный момент не так много партнеров используют технологию VAIO для своих продуктов, а категорий решений всего две - репликация и кэширование. Но VMware активно работает в этом направлении, и в скором времени, возможно, мы увидим еще несколько продуктов, реализующих функционал IO-фильтров для решения новых задач.

На прошедшей конференции VMworld 2017 в рамках сессии "VMware Virtual Volumes Technical Deep Dive" компания VMware рассказала о технических аспектах технологии VVols, а также возможностях, которые появятся в следующей версии платформы виртуализации VMware vSphere:

Самый интересный слайд показывают в конце презентации:

Во-первых, надо отметить, что следующая версия vSphere будет иметь номер 6.7, а, во-вторых, давайте посмотрим на три фичи, которые появятся в VVols, подетальнее:

• Support for Microsoft Cluster Server (MSCS) – это была одна из причин, по которой администраторы до сих пор используют RDM, а этот вариант использования не поддерживается со стороны VVols. Данная поддержка позволит расширить сферу использования технологии.
• Performance parity with VMFS – в данном случае цель VMware - обеспечить высокую производительность VVols, поскольку сейчас есть промежуточный компонент Protocol Endpoint, который замедляет работу подсистемы ввода-вывода. Также будут оптимизированы такие операции как bind, соединения VASA, а также обработка метаданных томов VVols. Кстати, в целом-то VVols должна работать даже побыстрее, чем VMFS.
• IPv6 support – платформа vSphere уже давно поддерживает IPv6, а сами VVols будут поддерживать IPv6 на уровне службы VASA Provider.

Поддержка NFS 4.1 и операций BIND/UNBIND/REBIND. Сейчас они делаются через VASA provider, которые идут через control path, поэтому медленные, а будут работать через Protocol Endpoint (то есть data path, что быстрее).

Будем следить за новостями о новых возможностях VMware vSphere 6.7.

На конференции VMworld 2017 компания VMware представила интересную сессию "Tech Preview of Integrated Data Protection for vSAN", где рассказывалось о новых уровнях защиты данных в кластерах VMware vSAN.

Сейчас защита кластера обеспечивается за счет избыточности дисковых объектов, которые размещены на разных хостах, и, в зависимости от степени дублирования эти объектов (политика failures to tolerate), кластер vSAN переживает отказы некоторого количества хостов ESXi в случае сбоя. Но сбои бывают и другого характера: например, повреждение данных, которое будет отреплицировано на все дисковые объекты.

Поэтому на VMworld было рассказано о Integrated Data Protection - технологии, которая защищает данные во времени и позволяет обеспечить исполнение политик RPO (recovery point objective). Работает она за счет создания снапшотов виртуальных машин - локально или удаленно.

Во-первых, по умолчанию снапшоты будут храниться локально (local protection). VMware ставит перед собой цель сделать так, чтобы до 100 снапшотов одной виртуальной машины не сильно влияли на ее производительность. Сейчас если создать столько снапшотов - виртуальная машина у вас сразу же загнется.

Во-вторых, работать все это будет на уровне политики хранения механизма storage policy based management (SPBM), в рамках которой можно будет задать и откидывание снапшотов в удаленные локации, например, NFS-шары, Data Domain или облако Amazon S3 (remote protection).

К примеру, вы можете использовать локальную защиту данных снапшотами до 4 часов, а по прошествии этого времени откидывать их в облако.

Ну и, в-третьих, все это будет поддерживать последние нововведения механизма VSS, чтобы создавать консистентные снапшоты уровня приложений.

При восстановлении ВМ из снапшота можно будет выбрать одну из контрольных точек во времени, а саму ВМ можно восстановить в изолированном сетевом окружении (например, чтобы проверить ее работоспособность перед вводом в продакшен).

VMware обещает сделать Integrated Data Protection в ближайших версиях VMware vSAN, будем смотреть за анонсами VMworld Europe 2017 в ближайшие дни.

В VMware vSphere есть механизм для создания и анализа кастомных алармов - VMkernel Observations (VOBs). VOB'ы - это системные события, которые можно использовать для пользовательских алармов в целях отладки различных аспектов виртуальной инфраструктуры (сетевого взаимодействия, кластеров vSAN, производительности и т.п.).

Чтобы добавить такой аларм, нужно знать его уникальный идентификатор (ID), ассоциированный с конкретным типом события. Эти события и их ID можно посмотреть в следующем файле на хосте ESXi:

/usr/lib/vmware/hostd/extensions/hostdiag/locale/en/event.vmsg

Если же такой аларм срабатывает, то он записывается в следующий лог-файл:

/var/log/vobd.log

Для того, чтобы создать кастомный аларм на основе VOB, нужно при создании нового аларма выбрать пункт "specific event occuring on this object":

И далее добавить соответствующий идентификатор, например, такой:

esx.problem.vob.vsan.pdl.offline

Событий, для которых можно создать кастомные алармы, очень много. Вот некоторые из них:

Ну а вот так вот будет выглядеть сработавший кастомный аларм в интерфейсе VMware vSphere Web Client:

Компания VMware на днях обновила свое основное решение для управления и мониторинга виртуальной инфраструктуры vSphere - VMware vRealize Operations Manager 6.6 (vROPs). Напомним, что прошлая версия Operations Manager 6.5 вышла в марте этого года.

Посмотрим на новые возможности VMware vROPs 6.6:

1. Улучшения юзабилити и user experience

• Новый интерфейс на базе HTML5
• Дэшборд Getting Started для быстрой навигации по задачам
• Дэшборды для пользователей, разделенные на категории: Operations, Capacity and Utilization, Performance Troubleshooting, Workload Balance, а также Configuration and Compliance
• Интеграция с решениями vSAN and vRealize Automation

Кстати, видео о новых дэшбордах vROPs можно посмотреть вот тут.

2. Нативные возможности управления кластерами vSAN

• Централизованное управление растянутыми кластерами (stretched clusters)
• Возможность полного управления решением vSAN, включая производительность, емкости хранения, логи, конфигурация платформы и ее состояние

3. Полностью автоматизированная балансировка рабочих нагрузок

• Балансировка систем по производительности на уровне датацентра между кластерами и хранилищами
• Учет DRS-конфигураций и предоставление возможности установки уровня автоматизации DRS для отдельных объектов
• Механизм Predictive DRS для предотвращения затыков производительности
• Учет исторических данных для первоначального размещения виртуальных машин

Об этих новых возможностях также есть серия видеороликов.

4. Дополнительные возможности по приведению систем в соответствие требованиям (compliance)

• Возможность анализа систем на требования vSphere Hardening
• Поддержка стандартов PCI и HIPAA
• Проверка соответствия бизнес-требованиям в дэшбордах cluster, host и VM configuration
  

5. Управление затратами и планирование

• Возможность просмотра затрат на облачные сервисы AWS и Azure
• Возможность отслеживания использования ВМ в публичных облаках
• Планирование инфраструктуры за счет учета влияния потребляемых дисковых емкостей на затраты

6. Прочие улучшения

• Поддержка Windows Server 2016 для агентов End Point Operations
• Агенты End Point Operations Management собирают метрики для смонтированных файловых систем NFS
• Интеграция с решением VMware vRealize Log Insight

Загрузить обновленную версию решения VMware vRealize Operations Manager 6.6 можно по этой ссылке. Release Notes по продукту доступны тут.

Вот и прошел первый официальный день конференции VeeamON 2017, которая проходит сейчас в Новом Орлеане. Это был отдельный день для партнеров Veeam и специалистов Veeam Vanguards. Я отношусь к обеим категориям, но в основном присутствовал на митингах для вангардов, где большинство контента было под NDA, поэтому насчет закрытой информации сказать ничего не могу, но из официальных анонсов было также много многообещающего.

Кстати, на митинге для вангардов было много интересных людей, включая ключевых сотрудников Veeam, таких как Антон Гостев и Леша Васильев (его я не видел больше 10 лет!).

Veeam как всегда щедро относится к своим гостям - вангарды получили в этом году брендированные эпловские наушники Beats стоимостью 300 баксов:

Ну а теперь к анонсам первого дня. Во-первых, был официально представлен Veeam Backup and Replication 9.5 Update 2, который вам потребуется для работы с продуктом Veeam Agent for Microsoft Windows 2.0.

Вот какие новые возможности появились в главном решении для резервного копирования виртуальных машин:

1. Поддержка новых платформ:

• Cisco HyperFlex Systems (бывший HX-Series/SpringPath) - поддержка функциональности Backup from Storage Snapshots.
• HPE 3PAR StoreServ 3.3.1 - поддержка и улучшенная масштабируемость за счет миграции некоторых API-вызовов с SSH на RESTful API.
• Поддержка платформы Microsoft Hyper-V BigEndian.
• Поддержка Microsoft Exchange 2016 CU5 для восстановления почтовых ящиков через Veeam Explorer for Microsoft Exchange.
• Поддержка NetApp ONTAP 9.1.
• Поддержка Oracle 12.2 для функциональности резервного копирования и восстановления баз данных.
• Veeam Agent for Linux 1.0 Update 1 (build 1.0.1.364) - поддержка обновленного агента, включая возможность 1-Click FLR через Veeam Backup Enterprise Manager.
• Veeam Agent for Microsoft Windows 2.0 (build 2.0.0.700) - поддержка обновленного агента, включая восстановление на уровне приложения.
• Поддержка VMware vCloud Director 8.20.
• Поддержка VMware vSAN 6.6.

• Восстановление файлов в оригинальное местоположение. Если его найти не удается, то мастер спросит о размещении восстановленных файлов.

• Улучшение производительности процесса Failback. Теперь changed block tracking используется для отслеживания изменившихся блоков между оригинальной ВМ и репликой.

• Опциональное создание NFS-шар. Теперь можно предотвратить их автоматическое создание, сняв галку “Create required NFS export rules automatically” в мастере New NetApp Storage.
• Улучшения производительности для операции Backup from Storage Snapshot with application-aware processing.

• Поддержка LTO7 path failover.
• Добавлена поддержка драйверов Exclusive (для драйверов non-exclusive она уже была).

• Улучшения VeeamZIP - теперь удобнее выбирать катлог назначения.
• Пресет ExaGrid - изменено дефолтное значение одновременных задач с 1 до 10.

• Улучшения Start-VBRZip - добавлены параметры сетевой аутентификации на сетевых шарах.
• Улучшения импорта бэкапов - теперь их можно импортировать из репозиториев DELL EMC Data Domain и HPE StoreOnce.

• Автообновление компонентов - теперь можно поставить галку для этого во время установки (кроме модулей Network Extension Appliances).
• Улучшена производительность апдейтов - теперь можно обновлять до 10 компонентов одновременно (эта величина настраивается).
• Установка обновлений больше не требует ручного отключения задач и служб Veeam (но задачи не должны быть запущены).

• В Update 2 появилась функциональнсть Veeam Backup Remote Access, улучшения механизма репортинга для Veeam Cloud Connect, а также было исправлено несколько ошибок.

Скачать обновление Veeam Backup and Replication 9.5 Update 2 можно по этой ссылке.

Также на VeeamON было объявлено, что Veeam Backup and Replication 10 будет поддерживать восстановление из реплик в среду VMware vCloud Director, что является приятной новостью для сервис-провайдеров, которые работают с несколькими клиентами в vCloud Director и хотят использовать Veeam Cloud Connect Replication в рамках услуги Disaster Recovery as a Service (DRaaS).

Кроме этого, бэкап Microsoft Office 365 будет поддерживать нескольких клиентов (Multi-Tenancy), что также полезно для сервис-провайдеров.

Ну и последнее, но весьма важное - было объявлено о выходе Veeam Availability Console v2 (бывший Veeam Managed Backup Portal) - унифицированном средстве для управления виртуальными, физическими и облачными рабочими нагрузками.

Пока это все, а завтра будет кое-что поинтереснее. Следите за нашими обновлениями!

Недавно на сайте проекта VMware Labs появилась интересная утилита - Host Profiles CLI. Она позволяет администраторам VMware vSphere из командной строки выполнять те операции, которые недоступны в графическом интерфейсе механизма настройки хостов ESXi Host Profiles или доступны ограниченно (без средств автоматизации). Особо стоит отметить возможность совместного использования механизмов Auto Deploy и Host Profiles CLI.

Напомним, что профили хостов (Host Profiles) - это средство конфигурации серверов ESXi таким образом, что единый "золотой" профиль применялся к всем хостам, настраивая их единообразно, что уменьшает риски ошибок конфигурации, а также улучшает управляемость/обслуживание инфраструктуры и ее безопасность.

С помощью Host Profiles CLI из командной строки можно делать следующее:

• Кастомизация stateless-хостов Auto Deploy до их загрузки и присоединения к vCenter Server.
• Импорт/экспорт профилей хостов из локальных файлов.
• Привязка профиля к существующему кластеру.
• Установка единого рутового пароля в профиле или настройка профиля таким образом, чтобы использовать уникальные пароли root для каждого из хостов.
• Настройка системного кэша (stateless, cached или stateful install).
• Просмотр всех профилей хостов, доступных на vCenter Server.

Напомним, что начиная с vSphere 6.5, для механизма Host Profiles можно указывать параметры кастомизации отдельных хостов (IP-адреса, пароли и прочее) в CSV-файле. Но это можно делать только для хостов, которые были уже добавлены в Inventory сервера vCenter. С помощью Host Profiles CLI можно сделать прекастомизацию хостов через файлы CSV, которые будут развернуты через Auto Deploy (то есть, самих хостов пока еще нет в vCenter).

Ну и вот так можно делать импорт и экспорт профилей хостов (не пытайтесь делать импорт профиля для окружения с другим оборудованием хост-серверов):

# hostprofilescli hostprofile --profile esxi65-nfs-gen8 export --file esxi65-nfs-gen8.vpf

# hostprofilescli hostprofile --profile esxi65-nfs-gen8 import --file esxi65-nfs-gen8.vpf

А вот так можно установить пароль root для всех хостов один или свой для каждого:

hostprofilescli hostprofile --profile esxi65-nfs-gen8 useraccount-password set --type allhosts

hostprofilescli hostprofile --profile esxi65-nfs-gen8 useraccount-password set --type perhost

Таким вот образом можно привязать профиль к кластеру:

hostprofilescli hostprofile --profile esxi65-nfs-gen8 attach --entity dbcluster

Также посредством Host Profiles CLI можно установить тип развертывания хостов через Auto Deploy - Stateless caching (когда хост в случае массового сбоя и недоступности PXE-сервисов грузится из локальной кэшированной копии) или Stateful install (когда хост грузится с диска и уже больше не зависит от Auto Deploy). Вот как это делается:

hostprofilescli hostprofile --profile esxi65-nfs-gen8 system-image host set \

--type stateful-install --firstdisk_arguments localesx,local --ignore_ssd --overwrite_vmfs

Более подробная информация об использовании Host Profiles CLI приведена в документации. Загрузить этот интерфейс можно по этой ссылке.

Многим из вас известен продукт для организации отказоустойчивых кластеров хранилищ под виртуальную инфраструктуруру StarWind Virtual SAN. Он выпускается уже в течение многих лет и давно зарекомендовал себя как лучшее в отрасли решение для создания программных хранилищ для виртуальных машин VMware vSphere и Microsoft Hyper-V. Его основные возможности приведены тут и вот тут. А сегодня мы расскажем о том, что продуктом и всеми его функциями стало можно пользоваться фактически бесплатно!

В последнее время VMware отчаянно борется за то, чтобы сделать обновленную версию VMware vSphere Client (он же бывший HTML5 Client) полнофункциональной и поскорее заменить ею устаревший Web Client. Мы писали о том, что недавно было выпущено обновление VMware vSphere 6.5b, в состав которого вошел vSphere Client 3.7-3.8.

Но последний раз мы писали о возможностях vSphere Client 3.6 вот тут, поэтому давайте взглянем на функциональность VMware vSphere Client последних версий 3.7 - 3.9:

• Улучшенные графики производительности: можно выбирать объекты и счетчики.
• Возможность включить/выключить LED-индикаторы для Host Storage Devices
• Возможность пометить диск как Remote/Local в представлении Host Storage Device.
• Мониторинг компонентов Storage Providers для хранилищ VVol.
• Миграция виртуальных машин из одной виртуальной сети (VM Network) в другую.
• Возможность изменять настройки NetFlow на коммутаторе Distributed Switch.
• Компонент Content Library (пока представление read only для библиотек, шаблонов и других типов контента),
• Возможность удалить Content Library.
• Создание библиотеки Subscribed Library на странице Content Library.
• Действие "Erase device partition" в представлении Host Storage Devices.
• Возможность пометить диски Flash/HDD в представлении Host Storage Devices.
• Создание новых хранилищ NFS 4.1 с аутентификацией Kerberos.
• Поддержка Protocol endpoints для хостов ESXi и хранилищ.
• Возможность изменения конфигурации стека TCP/IP.
• Представление VM Customization Specifications в разделе "Policies and Profiles".
• Был произведен перевод приложения vSphere Client (HTML5) с фреймворка Angular Javascript (Angular 4) на последнюю версию Clarity. По идее, это должно пройти незаметно для пользователей, но возможны небольшие изменения во внешнем виде.
• Возможность создания хранилища VVol в мастере "New datastore".
• Возможность размонтировать тома VVol с хостов ESXi.
• Перемещение файлов и папок между датасторами в Datastore Browser.

Скачать VMware vSphere Client 3.9 можно по этой ссылке. Таблица отличий vSphere Client и Web Client приведена тут (смотрите на номер билда - данные там не самые актуальные).